home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc / Developer Documentation / Human Interface / Human Interface Q & A / HI Q&A #2 < prev    next >
Encoding:
Text File  |  1996-04-26  |  10.0 KB  |  202 lines  |  [ttro/ttxt]
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17. Q& A #2
  18.  
  19. By the Apple Computer OpenDoc Human Interface Team
  20.  
  21. As published in the February 1995 Apple Directions .
  22.  
  23. This is the second installment of Answers to Questions we've received about
  24. OpenDoc from engineers in the human interface community through conversation
  25. and e-mail.
  26.  
  27. Q: When a frame is resized, should the crop area of the contents change, or
  28. should the contents be scaled?
  29.  
  30. A: When the user resizes a frame, two part editors are involved--the editors
  31. for the container and the embedded part. When the user has selected a part
  32. frame and resized it, the default behavior of the selected part's editor
  33. should be to change the cropping of the content. For example, if the
  34. selected part is a spreadsheet, resizing will show more or fewer cells.
  35. Optionally, your part editor may have a setting to allow the user to specify
  36. "change cropping" vs. "scale to fit frame." For "scale to fit frame," the
  37. currently visible content should expand or contract to fill the resized
  38. frame. We recommend that your application change the cropping of the resized
  39. frame as the standard behavior for resizing. If your editor supports scaling
  40. of embedded content, you should employ a separate mechanism for scaling.
  41. Consult the OpenDoc Human Interface Guidelines for the Macintosh for a
  42. description of different approaches.
  43.  
  44. Q: Some of today's applications support different modes. For example,
  45. HyperCard allows several modes, including use mode, several different edit
  46. modes, and a paint mode. How should multiple modes be implemented in
  47. OpenDoc?
  48.  
  49. A: By all means, use multiple modes for your part if that makes sense. Do
  50. follow the standard development guidelines for making the kinds of visual
  51. distinctions that will help users identify which mode they're in. For
  52. example, use distinct tools other than the standard arrow tool for different
  53. modes.
  54.  
  55. Q: My part editor supports different tools. What should happen when my part
  56. becomes inactive? For example, if a paint part is set to the eraser tool,
  57. should it remain so when the frame becomes inactive?
  58.  
  59. A: Since the guidelines suggest that cursor feedback over inactive parts
  60. should be the content-specific cursor, the part should retain its tool state
  61. when it becomes inactive. However, there are exceptions. Because OpenDoc
  62. uses inside-out activation, some tool states can cause the user to make
  63. inadvertent changes to content. For example, a single click in an inactive
  64. frame whose tool is set to the eraser could erase content; a single click in
  65. an inactive frame whose tool is set to the draw tool would create a point.
  66. Therefore, when your part becomes inactive, change to a safe, neutral tool
  67. such as a selection tool. This is consistent with the way many applications
  68. work today: Tools such as the eraser tool work for only one time, then
  69. revert to the selection tool.
  70.  
  71. Q: The linking functionality is hidden within copy and paste. Why doesn't
  72. linking have its own command, such as Paste Link, instead of hiding under
  73. Paste As?
  74.  
  75. A: Copying is copying. In fact, both copying and dragging are simply
  76. transferring data. Copying is a simple-to-use, fundamental operation.
  77. Linking is a feature of copying that allows the resultant pasted copies to
  78. stay synchronized. The mental model we want to support is that linking is
  79. just an automatic method of copying. This adds some interesting complexity
  80. to the copy operation. OpenDoc hides this complexity from the user except
  81. when the user needs explicit control of pasted content. In that case, the
  82. user may indicate whether copied content should simply be pasted, or pasted
  83. and linked to the original. Additionally, copied content can be pasted as an
  84. embedded part or merged with the destination. Since linking has the same set
  85. of options as a paste operation, linking is implemented in OpenDoc as a part
  86. of the paste operation.
  87.  
  88. Q: In OpenDoc, how would I make annotations in the margins of a document?
  89. Can I drop annotations in as a part?
  90.  
  91. A: The part developer can choose to support this feature. In OpenDoc, every
  92. part (except the root part) can be thought of as being contained within
  93. another part. Each container controls the layout of its embedded parts. A
  94. container may allow the user to place a part inside the margins of a page,
  95. but the container editor must be written to support that capability. The
  96. container editor would need to detect the case where the user drags a part
  97. or piece of content to the margins, and then place the dragged item there.
  98.  
  99. Q: Every document should be viewable. Why doesn't OpenDoc allow part viewers
  100. to be included in the document?
  101.  
  102. A: We agree that every document should be visible, but encapsulating
  103. multiple part viewers into a document needlessly swells the size of the
  104. document, just as always storing a PICT file for every part does. We
  105. discussed viewers and translation as OpenDoc's answer to the "missing
  106. editor" problem in last month's article. OpenDoc allows the part to store
  107. multiple data formats for a part. And while a PICT may be appropriate in
  108. some circumstances, other formats are often more compact.
  109.  
  110. We considered a "Make Self-Contained" feature that would produce a document
  111. with all the necessary viewers encapsulated but decided against this,
  112. because it looked like a route for viruses. Also, we see this as a
  113. third-party opportunity for creating tools that produce self-contained
  114. documents.
  115.  
  116. Q: When the user opens a part into a window using View In Window, should my
  117. editor save those window positions?
  118.  
  119. A: We don't see any reason for OpenDoc parts to deviate from the standard
  120. Macintosh human interface guidelines for windows. To reiterate those
  121. guidelines: Before closing a window, check to see whether the user has
  122. changed its size or position. Save window positions, and reopen windows in
  123. the size and position in which the user left them. If a user opens, moves,
  124. and closes a document window without making any other changes, save the new
  125. window position but don't modify the date stamp of the document. If the user
  126. does not change the size or position of the window, don't save the position
  127. when the user closes the window. Before reopening a window, check to make
  128. sure that the size and state are reasonable for the user's current monitor
  129. or monitors, which may not be the same as the monitor on which the document
  130. was last open.
  131.  
  132. Q: Can I use a Window menu for subordinate windows and window-management
  133. commands such as Tile and Stack?
  134.  
  135. A: OpenDoc uses the Application menu (also known as the Process menu) as a
  136. way to find the documents that are currently open. So, in contrast to
  137. today's model, in which a Window menu shows only the windows of the current
  138. application, in OpenDoc the Application menu is system-wide. Therefore, we
  139. recommend limiting the use of any Window menu to situations in which there
  140. are multiple views of a document, such as subordinate windows. For example,
  141. in a CAD system, it may make sense to list these views or related commands
  142. in a Window menu. In this case, you should consider whether a View menu
  143. adequately addresses their needs before resorting to a Window menu. See the
  144. OpenDoc Human Interface Guidelines for detailed discussion of these menus.
  145.  
  146. Q: Does OpenDoc allow copied content from a non-OpenDoc application to be
  147. pasted into an OpenDoc document?
  148.  
  149. A: Yes. The first thing to keep in mind is that the transferred data is not
  150. a part, it's just data. There are two cases to support: (1) the destination
  151. part can receive the data and merge it into itself; and (2) the destination
  152. part can't merge the data but allows it to be embedded. When a destination
  153. receives a paste or drop, it looks at the contents and tries to incorporate
  154. or merge the data into its contents. For example, suppose some text from a
  155. word processor is pasted into an OpenDoc text part. The OpenDoc text editor
  156. sees that one of the kinds of data available on the Clipboard is text and
  157. pastes it in. In fact, there are often different kinds of content available.
  158. In this case, there may be simple text as well as richer formats such as
  159. styled text. The OpenDoc text editor should use the richest format possible
  160. in order to preserve information.
  161.  
  162. If the content on the Clipboard is of similar kind, then it can be
  163. incorporated into the destination. The destination part determines whether
  164. the content is similar by using the kind of the content to look up its
  165. category. If the category is the same as the destination, then translation
  166. is used to incorporate the content.
  167.  
  168. If the category is different from that of the destination, then a part of
  169. the appropriate kind is created to store it, and it is embedded in the
  170. destination part. If the contents being added were created with SurfWriter,
  171. then a SurfWriter kind of part is created; if the SurfWriter editor is not
  172. available, then the part is defined by the user's preference. So, if the
  173. text is then pasted into SurfDraw, the system examines the user's
  174. preferences (set in the Editor Preferences control panel on the Macintosh
  175. computer), creates a part of the preferred kind within the drawing, and
  176. finally puts the pasted contents into that part.
  177.  
  178. Q: In embedding OLE parts, when should OLE standards be used and when should
  179. OpenDoc standards be used?
  180.  
  181. A: We believe that OpenDoc provides a better overall user experience than
  182. OLE 2.0. Thus, whenever OLE objects are embedded within OpenDoc documents,
  183. we attempt to present an OpenDoc experience. For example, the menus are made
  184. to match the OpenDoc standard. However, it is not always possible to make
  185. these OLE objects behave exactly like OpenDoc parts. Therefore, we use the
  186. OLE visual feedback for OLE parts so that the user will at least know that
  187. these are not standard OpenDoc parts.
  188.  
  189. Q: What kind of standards exist for common command elements, such as menus
  190. and tool bar buttons?
  191.  
  192. A: We are working with CI Labs to create standards for tool bar icons,
  193. placement of items and frequently used menus, tool bar reuse, and standard
  194. icons. If this is an area you're interested in contributing to, please
  195. contact us.
  196.  
  197. Authors: Dave Curbow and Elizabeth Dykstra-Erickson writing for the OpenDoc
  198. Human Interface teams.
  199. _______________________________________________________
  200.  
  201. Copyright (c) 1995 by Apple Computer, Inc. All Rights Reserved.
  202.